Closed
Bug 318581
Opened 19 years ago
Closed 15 years ago
Bottom borders on items inside <li> tags sometimes missing
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: cefrodrigues, Assigned: roc)
References
()
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 I've noticed that, since upgrading to Firefox 1.5, some items inside <code></code> blocks on DokuWiki generated pages are missing the bottom border. After some tests I concluded that this only happens when the "<pre></pre>" block generated from those "code" tags ends up inside a "<li></li>" block. This works fine on other browsers and previous versions of Firefox. Reproducible: Always Steps to Reproduce: 1. Go to the URL mentioned above 2. Look at item "5" on the "MacOS X and Apache" section. Actual Results: The block is missing a (dashed) bottom border, but the other blocks are not. Expected Results: All block should have a (dashed) bottom border.
Reporter | ||
Updated•19 years ago
|
Version: unspecified → 1.5 Branch
Assignee: nobody → roc
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → ian
Version: 1.5 Branch → 1.8 Branch
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
This seems like a rounding issue to me. It might be useful to know when this regressed.
Keywords: testcase
Reporter | ||
Comment 3•19 years ago
|
||
The test case works fine. Maybe because the "pre" tags aren't inside "li" blocks.
Comment 4•19 years ago
|
||
Hmm, apparently the bug in the testcase only shows in my debug build.
Comment 5•19 years ago
|
||
Yes, all the borders show up here in the testcase. It is a fairly recent regression: 1.9a1_2005083014 - 1.9a1_2005083018. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-30+13%3A00%3A00&maxdate=2005-08-30+18%3A00%3A00&cvsroot=%2Fcvsroot
Comment 6•19 years ago
|
||
I found also the regressionrange for branch (3 weeks later): 1.8b5_2005092010 - 1.8b5_2005092022. They have one patch in common: bug 192077. http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-09-20+09%3A00%3A00&maxdate=2005-09-20+22%3A00%3A00&cvsroot=%2Fcvsroot
Reporter | ||
Comment 7•19 years ago
|
||
Still happening with 1.5.0.1
Reporter | ||
Comment 8•18 years ago
|
||
This bug is still present in 1.5.0.3.
Reporter | ||
Comment 9•18 years ago
|
||
This page [http://s1x.homelinux.net/documents/ffox_glitches/] shows the same problem, also with "pre" elements but not inside a "li" block. I think this may be the same problem. (Tested with Fiefox 1.5.0.4 on Windows.)
Comment 10•17 years ago
|
||
attachment 207636 [details] WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 The "Steps to Reproduce" no longer work as the document at the original URL has been altered. http://s1x.homelinux.net/documents/ffox_glitches/ indicates some of the problems were fixed in 1.5.0.4.
Reporter | ||
Comment 11•17 years ago
|
||
Reporter | ||
Comment 12•17 years ago
|
||
The problem persists in Firefox 2.0.0.3, as you can see in attachment #261728 [details].
Comment 13•17 years ago
|
||
It appears to be fixed on trunk, somewhere in January 2006. Don't know if this bug should stay open (in case someone wants to fix it on branch).
Comment 14•17 years ago
|
||
I have reduced this test case down to a single HTML page, and the result is that I am not sure this is a rendering problem. To illustrate this, change the dashed border from 1px to 2px to see that one pixel is then displayed. div.dokuwiki pre { .. border:2px dashed #8CACBB; .. }
Attachment #261728 -
Attachment is obsolete: true
Reporter | ||
Comment 15•15 years ago
|
||
I haven't seen this behavior for a while. This appears to be fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•